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Abstract 



Modern PC workstations often provide more CPU power 
than required for most control applications. On the other 
hand, the screen space is always in short supply. One pos- 
sible solution is to use more PCs, but in fact we need only 
more screens, not more keyboards, mice etc. PC architec- 
ture allows using more than one videocard, and X Win- 
dow protocol is also aware that there can be more than 
one screen. But until release of XFree86 version 4 there 
was no freely available server capable of driving multi- 
ple "heads". We have been using multiheaded worksta- 
tions under XFree86 in the VEPP-5 control room since 
early 2000 (currently 4 4-headed PCs plus several dual- 
headed). The "Xinerama" mode (one-large-screen) is bet- 
ter suited for accelerator control system than "several sep- 
arate screens". When moving to this configuration we've 
encountered a number of, mainly human-related, prob- 
lems, some of which required modifications to X server 
Additionaly, the "style" of performing control has slightly 
changed. 

1 NEED IN MORE SCREEN SPACE 

Historically automation at BINP is based on CAMAC. A 
home-made Odrenok [[![] machines were used as both crate 
controllers and as the main computational power. The in- 
formation was displayed via CAMAC -based display con- 
trollers, which gave color 256x256 pixel picture. That al- 
lowed sufficient display space for most tasks. 

On the new VEPP-5 facility the computation and high- 
level control was moved from crate controllers to Intel- 
based workstations. So, the aging CAMAC display hard- 
ware wasn't an option. 

Modern video cards and monitors have resolutions large 
enough to simply put contents of all 256x256 displays on 
them. 

This approach was taken by the VEPP-4 team, which 
exploits a large number of legacy programs using CAMAC 
display controllers. They made an emulation library, which 
redirects graphic output of such programs to XI 1 windows. 
But there was no reason for VEPP-5 to go this way. 

2 POSSIBILITY 

PCI bus allows to have multiple videocards in one com- 
puter. One card is treated as primary (the one on which 



the boot screen appears), and others are inactive until a 
multihead-aware system is loaded. AGP slot looks like just 
one more PCI slot. 

From the very beginning X theoretically allowed to use 
several screens on one host. These screens are referred to 
as hostname :N.O, hostname:N.l , etc., where N after semi- 
colon is a display number (typically 0) and 0, 1, etc. after 
dot is a screen number. 

But in practice, XFree86 up to version 3.x inclusive 
didn't support multihead. That capability appeared in long- 
awaited version 4.0, released in early 2000. 

3 TRADITIONAL MULTIHEAD VS 
XINERAMA 

The traditional X multihead presents each screen sepa- 
rately, so that when a window is created, it is placed on 
one of these screens and cannot span screens or be moved 
from one screen to another (see Fig.[j],a). 
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b. Xinerama 

Figure 1 : Traditional and Xinerama multihead 

On the other hand, Xinerama makes multiple physi- 
cal screens behave as a single screen, transparently to the 
clients (see Fig.JiJb). So, the windows can be freely moved 
between screens. 

A good source of information about Xinerama is M\. 



Since the situation on the screen of control computer 
isn't static (there's often a need to group windows in dif- 
ferent ways, to move more important windows to "more 
visible" screen), Xinerama is much better suited for use in 
a control room than traditional multihead. 

4 XINERAMA PROBLEMS 

4. 1 Technical problems 

When joining screens, Xinerama leaves only depths which 
are common to all screens. So, it is impossible to join 16- 
bit screen with a 24-bit one. Additionally, the 24+8 "over- 
lay" feature of Matrox cards is lost, since 2nd head doesn't 
support it. 

But the main inconvenience is that since all screens look 
like a single one to all clients, the window managers hap- 
pily place windows between screens, maximize them on all 
screens, etc. 

We use FVWM [Q] in the VEPP-5 control room, so we 
invested some time to its initial xineramification, which 
was completed by FVWM team (now Xinerama support 
in FVWM is probably the most complete and configurable 
among all WMs). Currently, most WMs are Xinerama- 
aware, but some toolkits still aren't]] 
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b. Overlapping 
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c. Disjoint heads d. Incomplete grid 

Figure 2: Possible Xinerama layouts 

And there is one more exotic problem. Technically, Xin- 
erama makes a single large desktop with a size of a bound- 
ing rectangle of all screens. And screens themselves func- 
tion as viewports to the desktop. So, Xinerama allows to 
place heads in many different ways (see Fig.|[). 

a Heads can form a regular grid - that's the most com- 
mon case. 



b They can overlap (a so-called "clone/zoom" mode). 
This is used very rarely, since the position of "zoom" 
screen is fixed and can't be moved e.g. following the 
pointer. 

c Can be disjoint^. 

d Or the grid can be incomplete. 

In the two latter cases, there are "black holes" on the 
desktop, which aren't visible on any monitor and which 
can't be reached with mouse. The consequences are worst 
in the last case - even complete windows can disappear in 
the black hole. 

Additionally, there are still some problems with software 
which either requires a direct access to framebuffer, or uses 
a fullscreen mode (various video capturing and movie play- 
ing programs).^ ^ ut ' tnan k:s to XVideo extension, these 
problems became very rare. 

4.2 Human Problems 

Some of our software developers are greedy: when they 
see so much display space, they say: "Hey, let's move this 
and this to another screen, and my program will just fill this 
screen". The common rule is "some programs tend to grow 
to occupy all screen space". So, appetittes of some people 
need reduction. 

Another problem is that mouse pointer often gets lost 
on large screen space. Finally a patch for X server was 
developed [S], which allows to 1) doublesize the pointer 
and/or 2) change the default colors from black&white to 
something more visible. We use red doublesized pointers, 
which provides good visibility. 

5 HOW MANY HEADS TO USE 

The most common multihead layout in the world is two 
heads: side by side horizontally, or one above another (if 
2nd head is used rarely). 

Three heads are hard to use: the layout will be either as 
on Fig^d, which is inconvenient, or lined up. In the latter 
case it takes too much time to move the pointer between the 
first and the last screens. When we had to use three heads, 
we put monitors in the shape of "r" but X layout was "three 
heads vertically". That setup was extremely confusing for 
operators. 

Four heads give the best balance between "as much 
screen space as possible" principle and convenience of use. 
When used in a 2 x2 grid, as on Fig.^,a, there are no black 
holes and the distance between heads is small. 



'A frequent case: a window with Yes and No buttons is centered, so 
that [Yes] goes to one monitor and [No] to the other one. 



2 That's a pathological case; more often screens of different sizes are 
used (e.g. 1024x768 and 800x600), which has the same effect. 

3 Up to XFree86 4.1 Xawtv behaved very funny: the window frame 
could be on one screen, and undecorated video picture - on another. 



6 HARDWARE 

6. 1 Criteria for selecting video cards 

First, that hardware should be multihead-capable (e.g., 
3Dfx cards are known not to work in multihead mode un- 
der XFree86 at all). Second, it must have good support in 
XFree86 and work very stable. Third, it should produce an 
excellent picture and have good 2D performance (3D isn't 
important). Fourth, video hardware should occupy as little 
PCI slots as possible. 



6.2 Solution we use 

There were 4 main manufacturers: ATi, Matrox, nVidia and 
S3 (the latter is almost dead now). We chose Matrox, be- 
cause 1) it satisfied all our criteria; 2) we already had very 
positive experience with their products. 

As to other two brands: nVidia doesn't open specifica- 
tions of their cards, so that XFree86 driver is very lack- 
ing, but instead nVidia provides binary-only driver; ATi 
cards are not-so-good and there are myriads of subversions, 
which affects stability of the driver. 

We use Milleniumlls as PCI cards, but any PCI card with 
4M or more memory[| would do (Millenium, G100, G200). 

6.3 Multiheaded videocards 



a. AGP + 3 PCI 



b. G450DH AGP + 2 PCI 



c. G450AGP + G450PCI d. G200MMS PCI 

Figure 3: Hardware options for 4 heads 

One more advantage of Matrox cards is that since 1999 
they have two heads on one card (G400DH, G450, G550). 
So, to have 4 heads, an AGP G450 plus two PCI Milleniu- 
mlls were enough (see Fig. |Jb), thus using only two PCI 
slots (which are always in deficite in control machines). 

And Matrox produces a PCI version of G450, thus al- 
lowing to use only one PCI slot in addition to AGP (see 
Fig. |[c). Unfortunately, when running as non-primary 
card, the G450 (either AGP or PCI) requires an additional 
driver module, which is available as binary-only from Ma- 
trox (so-called HAL module [Eh). But we hope the na- 



tive XFree86 support will become better soon, thus making 
HAL redundant. 

Currently two of our 4-headed PCs are equipped 
with G450AGP+2xMilleniumII, and two are 
G450AGP+G450PCI. 

Theoretically there exists even a better choice - 
G200MMS, which supports 4 heads on one card (see 
Fig. ^|,d), but it exists in PCI version only, so if we 
need 4 heads total, it occupies the same one PCI slot as 
G400AGP+G450PCI. Additionally, G200MMS is almost 
impossible to find in Russia. 

6.4 Motherboards 

We chose ASUS P3B-F (Intel 440BX chipset), which has 
1 AGP slot, 6 PCI and one ISA (one position is shared, so 
you get either 6 PCI and ISA or 5 PCI and 1 ISA). The 
main requirement was a presence of ISA slot, since we still 
use old ISA hardware. 

7 FUTURE ENHANCEMENTS 

One feature our operators wish to have is an ability to 
control programs on adjacent computers with their mouse. 
A program x2x ^ exists which does exactly this, but it 
doesn't work with Xinerama. So, we plan to "xineramify" 
x2x. 

Currently the world moves to using TFT monitors, as 
those are more safe for people. But most TFTs have a lim- 
ited viewing angle, which is inappropriate in multiheaded 
system, and those TFTs which are okay (like SGI 1600SW) 
are too expensive. So, currently we use 17" CRT displays, 
but plan to replace them when affordable TFTs appear. 

Finally, consistent and ergonomic placement of windows 
on a 4-monitor desktop is a time-consuming task. So, we 
are planning to implement some sort of automation for this. 
Currently we are experimenting with X resource database 
(the WINDOWNAME. geometry resource). 
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